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® PROCEDE DE GENERATION AUTOMAT1QUE DUN MODULE D'UNE BASE DIN FORMATIONS 
D f ADMINISTRATION DE RESSOURCES INFORMAT1QUES. 

(|y Le precede de generation automatique un module 
(19) tfune base ^informations coadministration (MIB) tf une 
ressource informatique (11) representee par objets et in- 
duant une architecture d'objets dstribues (CORBA) selon 
un langage donne (IDL), consiste d former un fichier (100) 
cfun fichier de description (101 ) et (fun fichier (1 02) de clau- 
ses de generation automatique, une clause comprenant au 
moins un mot de determinant un mode de generation et au 
moins une caract6ristique sur taquelle porte un mot cl6, et & 
appiiquer le fichier (100) d des moyens de generation (52, 
54) pour obtenir le module. 
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Titre 

Precede de generation d'un module d'une base deformations 
d'administration de ressources informatiques. 

'4 

Oomaine technique. 

L'invention concerne l'administration d'au moins une ressource 
inform atique representee dans une technologie orientee objets. La ressource 
informatique peut etre un systeme informatique et/ou un reseau informatique 
et/ou une application informatique. L'invention a pour objet un precede de 
generation automatique d'un module d'une base deformations 
d'administration d'un tel systeme. La generation d'un tel module impliquant 
la modification des agents d'administration utilisant ladite base et d'un 
integrateur de ces agents, l'invention 8'applique aussi a la generation 
automatique d'un tel integrateur d'agents d'administration. 

L'invention est plus particulierement adaptee a un systeme 
informatique induant une architecture d'objets distribues, telle que 
rarchitecture CORBA (Common Object Request Broker Architecture) definie 
par le groupement de fournisseurs et dntffisateurs travaillant a la 
normalisation de la gestion des objets et connu sous le nom OMG (Object 
Management Group) et rarchitecture OLE/COM (Object Linking and 
Embedding / Component Object Modeler) de Microsoft. L'architecture CORBA 
sera prise comme exemple non limitatif dans la suite du texte. Dans le 
domaine de ftnformatique distribuee, l'architecture CORBA permet de 
decrire des interfaces de services informatiques independamment des 
fournisseurs et des langages mettant en oeuvre ces services. La description 
des interfaces est faite a l'aide d'un langage neutre de description d-interface 
connu sous le nom de langage IDL (Interface Definition Language) defini 
aussi par le groupement OMG. Ce langage definit les frontieres d'un 
composant que constitue un objet gere. e'est-a-dire les interfaces 
contractuelles du composant avec des clients potentiels. 
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L'invention a aussi pour objets corollaires 1 syst£me 
d'administration et le syst&ne infonnatique qui mettent en oeuvre le proced& 

L'art ant6rieur. 

5 L'administration de ressources informatiques est ordinairement 

faite par une plate-forme logicielle d'administration dont on conn ait plusieurs 
types. La plate-forme qui servira d'exemple par la suite est celle connue sous 
le nom de marque d6pos£e OpenMaster, commercialism par le demandeur. 
Cette plate-forme se fonde sur une technologie k objets. Selon cette 

10 technologie, les moyens constituant la ressource infonnatique sont convertis 
en classes d'objets organises hierarchiquement dans une base dHnformations 
d'administration MIB (Management Information Base). Invention 
s'applique k la g6n6ration d'une partite, nominee module, de cette base. 

D'autre part, la plate-forme servant d'exemple utilise le protocole 

15 normalise de communication dedie k l'administration connu sous le nom de 
protocole CMIP (Common Management Information Protocol). Le protocole 
CMIP repose sur la norme ISO definissant les services pour le transfert des 
informations d'administration appeles services CMIS (Common Management 
Information Services). Ce protocole est organist selon un lan gage de 

20 description des informations d'administration appele langage GDMO/ASN.l 
issu de directives pour la definition d'objets ger6s (Guidelines for the 
Definition of Managed Objects) selon le module d*interconnexion connu sous 
le nom de marque d6pos£e OSI (Open Systems Interconnection) de 
I'organisme international de normalisation ISO (International Standards 

25 Organisation), et de syntaxe ASNl (Application Syntax Notation One). Pour 
des raisons de commodite, ce langage sera appele simplement GDMO. 

Un probl&me se pose quand l'administration de ressources 
informatiques au moyen de cette plate-forme utilise une architecture d'objets 
distribu6s telle que CORBA. Cette administration concerne non seulement 

30 l'architecture CORBA elle-meme, mais aussi les services ^applications 
coop&rant avec cette architecture. Ces services peuvent etre administres par 
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llntermediaire d'une interface d'administratioa publiee, decrite dans le 
langage IDL de l'aichitecture CORBA. A partir d'une description en langage 
IDL d'une interface d'un service CORBA, un compilateur IDL genere dans un 
langage de programmation, par exemple C++, du code dont une partie, 
connue sous le nom normalise "skeleton", permet de mettre en oeuvre le 
service et dont une autre partie, connue sous le nom normalise "stub", permet 
d'appeler le service a partir d'un autre programme sous forme de 
bibliotheque. L'agent mis en oeuvre com me service particulier de CORBA a 
done une interface decrite en langage IDL. Cette description est aussi la 
description de reformation d'administration ofiferte par l'agent. Le langage 
IDL sert ainsi a la fois de langage de description d'interface et de langage de 
description dlnformation d'administration. 

Le precede de generation automatique d'un module d'une base 
d'informations d'administration d'une ressource informatique representee par 
objets et incluant une architecture d'objets distribues CORBA selon le 
langage IDL, consiste actuellement & faire un fichier de description 
d'interface dans le langage IDL, a faire une conversion automatique du 
fichier et a compiler le fichier de description pour obtenir le module. 

Plusieurs algorithms de conversion sont conn us, tela que ceux 
publies par le groupe JIDM (Joint Inter-Domain Management) du groupe 
ORG. Dependant, ces algorithmes ne suffisent actuellement pas pour obtenir 
une version complete et exploitable en langage GDMO d'un module de la base 
MIB. Le probl&me est que des notions conceptuelles pouvant etre decrites en 
langage GDMO ne peuvent pas l'etre en langage IDL. Par consequent, on 
n'obtient qu'une partie seulement du module desire de la base MIB. 

La solution actuelle consiste a completer manuellement le code 
genere par la conversion, de facon a utiliser au mieux les caracteristiques du 
langage GDMO. Cette solution a done comme premier inconvenient d'etre 
couteuse en temps et en argent. De plus, ce travail manual doit etre reproduit 
apres chaque traduction dans le cas de changements du contenu du fichier de 
la description rendu disponible par un agent CORBA. C'est done une solution 
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ponctuelle, qui doit etre revue et completee pour etre adaptee a chaque cas et 
qui a pour second inconvenient d'etre limitee au cas d'espdce et d'etre 
d'autant plus couteuse qu*il y a de changements de la description. Or, 
1'evolution de cette technologie est rapide et s'avdre done trfcs couteuse. Le 

5 troisieme inconvenient est du au fait que le fichier de description en lan gage 
EDL est traite par un compilateur, qui oblige la modification de la syntaxe du 
lan gage IDL. La syntaxe est ainsi altera dans le seul but de la faire passer 
dans un generateur exterieur k 1'architecture CORBA. 

La generation d'un module de base MTB implique directement la 

10 modification des agents d'administration qui servent de liens entre 
l'architecture CORBA et la plate-forme d'administration, ainsi que le 
composant servant d'interface entre ces agents et la plate-forme et appele 
integrateur d'agents. Le raeme fichier de description IDL est utilise pour 
modifier les agents et Pintegrateur de ces agents. Alors que la modification 

15 des agents ne pose pas de probldme, la modification de Hntegrateur d'agents 
CORBA pose le meme probleme que celui expose precedemment. 

Sommaire de Tinvention. 

Un premier but de Invention est de g6n6rer automatiquement 
20 dans une base d'informations d'administration MIB un module plus complet 

que celui fourni par la conversion automatique actuellement disponible, le 

module desire etant suffisamment complet pour etre exploitable pour 

l'administration. Le module genere peut etre nouveau ou resulter d'une 

modification d*un module anterieur. 
25 Un second but est de generer un module de base MIB exploitable 

sans alterer le fichier de description IDL. 

Un troisieme but est de generer un module de base MIB 

exploitable et facilement adaptable aux changements de la description 

initiate. 

30 Un quatrieme but est de generer simplement et k moindre cout 

un module de base MIB exploitable. 



2793908, 

Un cinquieme but de ^invention est, comme consequence de la 
generation du module d'administration, de modifier automatiquement 
ilntegrateur d'agents d'administration sans intervention manuelle. 

L-invention a pour objet un precede de generation automatique 
d'un module d'une base d-informations d'administration (MTB) d'une 
ressource informatique representee par objets et induant une architecture 
d'objets distribues (CORBA) selon un langage donne (IDL), consistant a faire 
un fichier de description d'interface dans le langage donne et a appliquer 
ledit fichier a des moyens de generation automatique pour obtenir une partie 
dudit module, caracterise en ce qull consiste a ajouter audit fichier de 
description un fichier de clauses de generation automatique. une clause 
comprenant au moins un mot de determinant un mode de generation et au 
moins une caracteristique sur laquelle porte un mot de. et a appUquer le 
fichier de dauses auxdits moyens de generation pour completer ledit module. 

Accessoirement, le fichier de dauses et le fichier de description 
ne foment qu«un seul fichier. l«un des deux fichiers etant distingue de l'autre 
par une marque. 

De meme, les moyens de generation comprennent en outre un 
generates (54) pour la generation automatique d'une partie d'un integrates 
d'agents d'administration. 

I/invention a aussi pour objet un ysteme d'administration d'une 
ressource informatique representee par objets definis dans une base 
d-informatioM d'administration (NOB) induant un module, la ressource 
informatique induant une architecture d'objets distribues (CORBA) sdon un 
langage donne (IDL). caracterise en ce quil met en oeuvre ledit precede. 

Presentation des dessins. 

- La figure 1 est une vue synoptique d'un systeme 
d'administration d'un systeme informatique, le systeme d'administration 
mettant en oeuvre un precede de generation automatique d'un module d'une 
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base MIB et du precede en resultant pour la generation automatique d'un 
integrates d'agents d'administration. 

- La figure 2 est une vue synoptique detaillee dc la structure 
d\ine plate-forme d'administration du systeme d'administration repr6sente 

5 sur la figure 1. 

- La figure 3 est une vue schematique d'un arbre repr6sentatif 
d'un exemple de base MIB correspondant au systeme informatique represente 
sur la figure 1 et incorporant le module a gen^rer conform^ment k rinvention. 

- La figure 4 est une vue schematique d'une architecture d'objets 
10 distribues CORBA en liaison avec un integrateur d'agents CORBA de la 

plate-forme representee sur la figure 2. 

- Et la figure 5 est un organi gramme illustrant schematiquement 
le procede de generation automatique d'un module de base MIB, ce procede 
etant aussi utilise pour la generation automatique de l'integrateur d'agents 

1 5 CORBA represente sur la figure 4. 

Description detaillee d'exemples illustrant 1'invention. 

La figure 1 represente un systeme d'administration 10 d'un 
systeme informatique 11. L'exemple qui suit se rapporte au systeme 

20 d'administration et de securite connu sous le nom de marque depos6e 
OpenMaster du demandeur. Sa conception est conforme aux normes ISO de 
Padministration de systemes et reseaux. Dans ces conditions, les termes 
utilises seront conformes k cette norme, qui sont de langue anglaise, 
notamment les sigles et acronymes. D'autre part, les verbes "administrer" et 

25 "gerer" et leurs derives qui seront employes id traduisent tous deux 
indifferemment le verbe anglais "manage* 9 et ses derives. L'homme du metier 
conn ait Men ces normes. Compte tenu de leur masse informative, on ne 
donnera id que \es elements necessaires a la comprehension de rinvention. 

Le systeme informatique illustre 1 1 est distribue et compose de 

30 machines 12 (12a, 12b) organisees en un ou plusieurs r6seaux 13. Une 
machine est une unite conceptuelle tr£s large, de nature materielle et 
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logirielle, pouvant etre les moyens impliques pour executer une application 
donnee, des moyens pour executor une fonction donnee, un ordinateur, ainai 
qu'un systeme informatique dans une architecture a systemes en cascade. Les 
machines 12 peuvent etre done tres diverses, telles que stations de travail, 
serveurs, routeurs, machines specialisees et passereUes entre reseaux. Le 
systeme informatique 11 est ordinairement un systeme comprenant plusieurs 
processeurs 14, un processeur 14 etant par exemple illustre dans chaque 
machine 12, des moyens de memoire 15 pour contenir les logiciels et les 
donnees du systeme, et des moyens d'entree-sortie 16 servant pour la 
communication entre machines par rintermediaire du reseau 13 a l'aide de 
protocoles divers, ainsi que pour une ou plusieurs communications 
exterieures, par exemple pour Impression, la telecopie, etc. Un tel systeme 
peut par exemple gerer des donnees a distance, distribuer des donnees dans 
le cas d'un systeme de reservation, commander ^execution de programmes a 
distance sur des machines specialisees, partager localement des ressources 
physiques ou logicielles, et communiques 

Le systeme d'administration 10 a une architecture de type dient- 
serveur. Dans l'exemple illustre. les unites formant clients et serveurs dans le 
systeme d'administration 10 comprennent deux gestionnaires 17a formant 
serveurs et trois agents 17b formant clients. Une machine 12 induant un 
gestionnaire est dite machine gestionnaire ou serveur 12a et une machine 
induant un agent est dite machine geree 12b ou cliente. Les gestionnaires 
17a et les agents 17b sont relies entre eux par Kntermediaire du reseau 13. 
Dans l'exemple illustre. les deux gestionnaires sont relies entre eux, l'un des 
gestionnaires 17a etant relie a deux des agents 17b tandis que l'autre est 
relte aux trois agents. Les liaisons entre gestionnaires et agents peuvent etre 
tres diverses. D'autre part, les communications entre gestionnaires et agents 
peuvent se faire sdon un ou plusieurs protocoles, de preference normalises 
tels que les protocoles CMIP (deja dtf) et SNMP (System Network 
Management Protocol). Le protocole CMIP repose sur la norme ISO 
definissant les services pour le transfert des informations d'administration 
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appeles services CMIS (Common Management Information Services). Chaqu 
protocole est organise selon un langage de description des informations 
d'administration. Par exemple, le protocole SNMP utilise le langage SMI 
(Structure of Management Information) tandis que le protocole CMIP utilise 

5 le langage GDMO/ASN. 1 deja cite, et simplement appele GDMO. 

La figure 2 illustre la structure d*une plate-forme 
d'administration 20 du systeme d'administration 10. La plate-forme 20 peut 
etre limitee a une machine gestionnaire 12a, ou etre distribute parmi 
plusieurs machines gestionnaires. Pour des raisons de commodite, la plate- 

10 forme illustree dans la figure 2 sera limitee a une machine gestionnaire 12a 
et correspond ainsi au gestionnaire 17a. La plate-forme illustree 20 se 
compose de cinq blocs fonctionnels : un bloc 30 duplications en langage SML 
(Systems Management Language), un bloc 40 de services, un bloc 50 
d'integrateurs d'agents, un bloc 60 d'interface de gestionnaire, et un bloc de 

15 communication 70. 

Le bloc 30 d'applications indut un ensemble d'apptications de 
base 31 (core applications), une interface graphique d*utilisateur 32 appelee 
interface GUI (Graphic User Interface), un tableau de bord constituant un 
lanceur d'applications 33, une interface 34 de communication exterieure du 

20 bloc 30, et un ensemble 35 de fonctions de haut niveau. Dans Pexemple choisi, 
les applications 31 sont ecrites dans le langage SML et communiquent avec le 
bloc 70, utilisant le protocole CMIP et le langage GDMO, par Vinterface 34 
qui est done ici une interface SML/GDMO. ^interface GUI 32 permet a un 
utilisateur de se connecter a la machine 12a pour demarrer et arreter comme 

23 il le desire ses propres copies des applications de base 31. Le lanceur 
d'applications 33 presente un tableau representant les applications 31 sous 
forme generate par leur nom et/ou, comme dans l'exemple choisi, sous forme 
dlcdnes. n suffit de diquer sur llcdne choisie pour lancer l'application 
correspondante. Les fonctions de haut niveau 35 sont ajoutees pour offrir des 

30 fonctions particulieres et des interfaces graphiques correspondantes. 
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Le bloc 40 comprend plusieurs services, notamment un service 
41 de base d donnees CMIS, appele service CMIS-DB, un service 42 de 
schemes dlnformatioiis d'administration ou service MISS (Management 
Information Schema Service), un service 43 de journal d'alarmes et un service 
44 de journal d'evenements normalement connecte a un journal d'evenements 
non illustre. Le bloc 50 illustre contient seulement un integrateur 51 d'agents 
d'administration, appele ordinairement par le sigle AI (Agent Integrator) et 
affecte a un protocole particulier, ici le protocole CORBA, d'autres 
integrateurs d'agents pouvant exister pour le protocole SNMP, etc le 
protocole CMIP est utilise comme exemple dans la plate-forme 20. 
Llntegrateur 51 d'agents est connecte au bloc 70 et a un ou plusieurs agents 
17b fonctionnant sous le protocole correspondent, ici CORBA. Dans l'exemple 
illustre. le bloc 50 indut aussi des moyens de generation 52, 53 et 54 et des 
moyens de compilation 55 qui, d'une maniere generate, pourraient etre 
contenus dans une partie quelconque de la plate-forme 20. Le bloc d«interface 
60 permet a la plate-forme 20 de communiquer avec un autre gestionnaire 
17a du systeme 10. pouvant etre un supragestionnaire de niveau 
hierarchique superieur. Enfin. le bloc de communication 70 constitue un lien 
entre les autres blocs et est appele courtier de requetes CMIS ou distributee 
CMIS (CMIS Dispatcher), n contient un routeur 71 d'evenements, permettant 
aux composants d'administration de souscrire a des notifications 
d'evenement. un routeur 72 de commandes pour transmettre des requetea au 
composant destinataire et eviter aux applications de savoir quel composant 
•possede- cheque instance MOI, une infrastructure de securite 73. un 
gestionnaire 74 d'objets sous la ratine ROOT (ROOT Object Manager), et une 
horloge 75 (timer). 

Selon une option courante et avantageuse du systeme 
d'administration 10. un gestionnaire 17a gere aussi la machine gestionnaire 
12a correspondante ou gere tout ou partie des machines gestionnaires. Cela 
peut se faire de facon similaire a celle illustree precedemment, plus ou moins 
adaptee 4 cette option. L'exemple illustre ofiiel double avantage d fatiliter 



2793908 

-10- 
la lecture des dessins tout en permettant a l homme du metier de faire une 
generalisation du systeme decrit et illustre. 

Le systeme informatique 11 de la figure 1 se compose de moyens 
materiels ou logiriels, reels ou virtuels, tels que machines, imprim antes, 

5 circuits virtuels et applications. Le systeme d'administration 10 utilise ces 
moyens selon un modele de donnees oriente objets, dont on connait les 
principales caracteristiques : classes, objets, heritage, encapsulation, 
methodes (ici actions) et evenements. L'organisation des classes dans 
l'exemple choisi du systeme 10 est hierarchique. On distingue : l'arbre des 

10 classes, une dasse etant definie en subordination a une ou plusieurs classes 
meres ; et l'arbre des instances, une instance etant attachee a une ou 
plusieurs instances meres. En particulier, une dasse est definie par des 
caracteristiques nominees attributs, tels qu'un nom d'un compos ant du 
systeme et un etat depression. Un objet d'une dasse sera appele une 

is instance de la dasse. Dans l'exemple choisi, les moyens du systeme 
informatique 11 sont done convertis en dasses d'objets organisees 
hierarchiquement dans une base dHnformations d'administration MTB 
(Management Information Base). Cette base n'est pas une base de donnees 
proprement dite, mais est assimilable a un catalogue de caracteristiques 

20 puisqu'elle contient la description et le contenu de toutes les dasses gerees 
par le systeme d'administration 10. Dans la base MIB, les objets sont divises 
en dasses d'objets geres, dites dasses MOC (Managed Object Class). Un objet 
gere est une vue abstraite, definie pour les besoins de la gestion, d'une 
ressource logique ou physique d'un systeme. Chaque dasse MOC represente 

25 un type donne desdits moyens du systeme 11. A chaque dasse MOC peuvent 
etre attachees une ou plusieurs instances d'objets geres, appelees instances 
MOI (Managed Object Instance) et representant des occurrences actuelles 
desdits moyens. 

La figure 3 illustre un exemple de structure d'une base MIB. Elle 
30 a une structure arborescente, faite d'une racine ROOT a laquelle sont 
attaches des sous-arbres ou sous-MIB 18, id representatifs des trois machines 
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gerees 12b appelees Mac-a, Mac-b et Mac-c. Les sous-arbres 18 sont aussi 
representes sous forme synoptique dans la figur 1, en liaison avec les agents 
17b respectifs. La racine ROOT est contenue dans le gestionnaire 74 et les 
racines des sous-arbres seront appelees soua-racines correspondant au terme 
anglais RooUet. Ainsi, toute application 31 devant traiter un objet de la base 
MIB s'adresse au gestionnaire 74 pour acceder a l'objet Dans l'exemple 
illustre, on a suppose que chaque machine 12b a, comme represents sur la 
figure 1, trois cartes 19, a savoir une carte- reseau R, une carte video V et une 
carte-son A, de sorte que chaque sous-arbre 18 correspondant con dent les 
trois objets correspondants. Dans la figure 3, seul le sous-arbre 18 relatif a la 
machine Mac-b a ete developpe. On y voit que le sous-arbre 18 a la sous- 
racine Mac-b induant trois fils constitues par les trois objets respectifs carte- 
reseau, carte video et carte-son (R, V et A). Invention s'apphque a la 
generation automatique d'une partie de I'arbre, appelee module 
dlnformations d'administration 19 et faite d'au moins un objet gere MOC et 
dont la description en langage IDL est issue d*un agent CORBA 51. Le 
module est defini de facon abstraite par un trait fantdme dans la figure 3. 
L'invention a pour objet un precede de generation automatique d'un module 
19 a partir d'un fichier de description en langage IDL. ce precede etant mis en 
oeuvre dans un integrateur d'agent 51. 

Une instance dans la base MIB a un nom distinctif relatif RDN 
(Relative Distinguished Name) sous forme d'une liste d'assertions sur valeur 
d'attribut appelees assertions AVA (Attribute Value Assertion). Chaque 
assertion AVA est un couple <attribut de nommage> <valeur>, 1'attribut de 
nommage etant celui qui, dans la classe, permet identification unique d'une 
instance par rapport a son instance mere. Dans un gestionnaire 17a de 
l exemple illustre, un nom RDN est compose d'une seule assertion AVA, done 
d'un seul couple <attribut de nommage> <valeur>. D'une maniere generale, U 
est cependant possible qu un nom distinctif RDN ait plusieurs assertions 
AVA. Chaque instance dans la base MIB est identifiee de facon unique par 
son nom distinctif DN (Distinguished Name), qui est la suite des noms RDN 
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sur le chemin entre la racine et l'instance dans l'arbre des instances. Un sous- 
axbre d*une instance correspond a l'ensemble forme par l'instanc ell -meme 
et les instances qui lui sont subordonnees dans l'arbre des instances. 

Sous la racine ROOT de la base MIB est* attachee une sous- 

5 racine pour chaque service du bloc 40. Dans ce bloc le service CMIS-DB 41 
fournit une base de donnees des objets geres MOI destinee a leur persistance 
une fois que le gestionnaire a ete mis hors fonctionnement. II supporte toutes 
les classes MOC des services CMIS qui sont stockees localement dans une 
base de donnees. En outre, il fournit un ensemble de services ou fractions de 

io base, appelees aussi primitives, disponibles pour toutes les applications. Ces 
fonctions sont Men adaptees a la structure hierarchique de la base MIB. Elles 
incluent notamment les fonctions : M-GET pour lire une ou plusieurs 
instances, M-SET pour mettre a jour une ou plusieurs instances, M-CREATE 
pour creer une instance, M-ACTION pour activer une operation specifique 

15 sur une ou plusieurs instances et M-EVENT pour envoyer un evenement. Ces 
fonctions supportent les notions de filtrage offirant la possibility de filtrer les 
instances selon certains criteres portant sur leurs attributs et les notions de 
portee (scope) permettant de preciser le niveau de profondeur dans l'arbre des 
instances. 

20 Le service MISS 42 fournit les moyens dHdentification des objets 

geres, les moyens etant ceux definis initialement dans les documents de 
definitions GDMO contenus dans une description GDMO. II permet 
d'executer des processus de description pour entrer un nouveau jeu de 
definitions en utilisant un compilateur GDMO et des processus de recherche 

23 (retrieval processes) pour savoir comment une information d'administration 
anterieurement entree peut etre lue par n'importe quel compos ant de la 
plate-forme 20. Ces deux processus partagent une base de donnees appelee 
base de schemas dlnformations d'administration, souvent abregee en base de 
schemas ou base M1SB (Management Information Schema Base). EUe sert au 

30 stockage de tous les jeux correctement compiles des definitions dlnformations 
d'administration. La base est modelisee par une base MIB. Cela signifie que 
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la structure de ^information contenue dans la base de schemas est 
logiquement vue comme une base MIB et qu elle utilise elle-meme la notation 
GDMO. Cette vue logique de la base de schemas est une partie de la base 
NOB globale accedee par la plate-forme 20 et est appelee base MIB de 
schemas dlnformations d'administration. 

Ls mecanismes et modalites d'echange entre objets peuvent etre 
regis de diverses facons dans les machines. Parmi eUe, l'exemple choisi utilise 
les mecanismes et modalites regis par une architecture d'objets distribues, 
raichitecture CORBA en l'occurrence. Dans le domaine de llnformatique 
diatribuee, ^architecture CORBA permet de specifier des interfaces de 
services infonnatiques independamment des fournisseurs et des langages 
mettant en oeuvre ces services. La specification des interfaces est faite a l'aide 
d'un Ian gage neutre de description d'interface connu sous le nom de lan gage 
IDL (Interface Definition Language) defini aussi par le groupement OMG. Ce 
langage definit les frontiers d'un composant que constitue un objet gere, 
c'est-a-dire les interfaces contractuelles du composant avec des clients 
potentiels. 

On a vu que llntegrateur 51 d'agents sert dlnterfaces entre la 
plate-forme 20 et les agents correspondants 17b de l'architecture CORBA. 

La figure 4 illustre la structure d*une architecture CORBA 90 en 
liaison avec la plate-forme 20 par l«intermediaire de Kntegrateur d'agent 51 
de type CMEP/CORBA. L'architecture CORBA 90 comprend : un courtier 91 
de requetes d'objets ou courtier ORB (Object Request Broker) definissant un 
bus des objets CORBA ; un ensemble 92 de services CORBA definissant les 
infrastructures d'objets au niveau systeme qui etendent le bus ; un ensemble 
93 duplications CORBA ; un ensemble 94 dlnstallations CORBA (CORBA 
facilities) definissant les infrastructures horizontals et verticals qui sent 
utilises directement par Is objets d'affaire (business objects) ; et un 
compilateur IDL 95. 

Comme U a ete dit en introduction, le precede connu de 
generation d'un module de base MIB consist* a utiliser un fichier de 
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description IDL tel qu*indique dans Tannexe IB a la presente demande, qui 
fait partie de la description et k appliquer le fichier k un g6n6rateur 52 pour 
obtenir une partie dudit module, 

Pour la realisation du generateur 52, pn connait plusieurs 

5 algorithmes de conversion, notamment les algorithmes d'administration 
inter-domaine et connus sous le nom JIDM (Joint-Inter-Domain 
Management) issus du groupement OMG. Cependant, ils ne suffisent pas 
pour obtenir une version complete et exploitable en lan gage GDMO. Cette 
insuffisance est due au fait que des notions conceptuelles pouvant etre 

10 decrites en langage GDMO ne peuvent pas l'etre en langage IDL. Ces notions 

sont notamment : 

- la definition des attributs de nommage, 

- des regies de construction d'arbres connus sous le nom de liens 
de nommage et plus ordinairement name-binding, 

15 - 1'allocation d'identifieurs d'objets, et 

• totalisation d'une mdme description d'attribut dans des 

interfaces diflerentes. 

La solution k ce probldme consiste k ajouter au fichier de 
description IDL de l'annexe IB des commentaires pour la conversion, tels que 

20 ceux illustres dans l'annexe 1A. Selon Texemple de Tannexe 1, les 
commentaires de l'annexe 1A sont contenus dans une zone de commentaires 
solidaire du fichier de description IDL de Tannexe IB, la zone de 
commentaires pouvant pr6c6der ou suivre la description IDL. Dans ce cas, la 
zone se distingue des autres commentaires de la description IDL (annexe IB) 

25 par une marque, en Toccurrence la marque GEN. Selon une variante possible, 
les commentaires de Tannexe 1A pourraient etre contenus dans un fichier 
aunilaire k la zone illustree mais independant du fichier de description IDL. 
Dans ce cas, il suffit d'appeler le fichier de commentaires pour completer la 
description IDL. Ainsi, la description IDL peut toujours etre passle au 

30 travers du compilateur IDL 95, avec les memes rtsultats, puisque la syntaxe 
du langage n'est pas modifi^e. 
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La figure 5 Ulustre scbematiquement le precede. Le bloc 100 
comprend le ficbie, conatitu, du fichier de description IDL 101 ulustre dana 
l'annexe U et la zone de commentairea 102 illustr. nana 1'annexe IB Le 
ficbie, 100 est appbqu. a lentree du premier gen.rat.ur 52 pour generer le 
5 module 19 do base MB. Le module .9 es. done un fidoer d, de*ri,ti.n en 
langag. GDMO. Le module ,9 est ensuit, integrt dans la base MIB En 
pratique, dana rexen.pl. ulustre, .'integration du module 19 <Uns 1. bas. 
MB eat faite par cmapilation du module 19. La compilation est faite ici par 1, 
cmpuateur GDMO 55 illua« dans 1, figure 2. Le module 19 est directement 
io aarimilabl. par 1, compilateur 55. Le compilateur 55 a pour nam tdmoc dan, 
1. produi. OpenMaster d. I'exempl, consider.. D prend 1. description GDMO 
du module ,9 en entree, en verifie la syntax. «t entre cette description dan, 
" ^ MSS 42 * " «««« ^ *>« "ndre diaponibl. U ascription aux 
services 40 et aux applications 31 de la plate-forme 20. 

" U figure 5 Ulustre ausai un precede en reaultant pour la 

generation automatize de Kntegrateur 51. Ce, inUgrateur tel qufflustre 

mntl" ZTT d " mL en pretorote CMn> - U - «»' -t^steur 
CORBA 17b d. la figure 2 est form, selon la Unique aateri,ure. qui 

~ * ""^ ,e * ^P-on IDL 101 de r^nexe !B a lenW. 
» du compila^ur IDL 95. Un, premier, parti. 51, de Kntegrateur 51 est faite 
anas, apart, du cmnpilateur 95. En fait, 1. compuateur 95 fourni, un, part, 
dtu "skeleton- , fageo, CORBA et un, parte dite -.tub- a Kntegrateu, 51 
pmtr en oonstituer la premiere parte .... Uoe secoade parte 51b de 
hn«gr,teu, uam raite selon 1. technic anterieure. emmia. , 

ltn\ it 19 de ****** omo - — «**™- «. 

odapte . „ generattion autematiqu, dtategrateur d'agent , „artr d-un. 
*«np.io„ GDMO. ce, outil etan, appel. OPALMDK dana 1. predui, 
OpenMaster,. A note, teutefois que dan, ,a teebniqu. aoterieure. 1. module 
GDMO ete,, ce,u. compute manuellemen, more que ^ , Wtion , a „ 

tTT aUt ° maa,IUement >»e troimem, parti, 

55. de Integrate*, 51 est faite simplemen, et autematiquemeu, a parti, du 
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fichier 100 au moyen du troisieme generateur 54. Le g6n6rateur 54 convertit 
le langage IDL du fichier 100 en un langage, par exemple C et/ou C++ qui 
sert a faire un lien entre la partie 56a gen6r6e k partir du langage IDL et la 
partie 56b generee k partir du langage GDMO. 

Les commentaires Ulustr6s en annexe 1A sont donnds k titre 
indicatif et vont main tenant etre commentes. On a vu que la marque GEN est 
ajoutee au debut d'un commentaire pour etre interpretee par les g6n6rateurs 
52 et 54 comme debut de commentaire. Les commentaires se composent de 
clauses ayant chacune leur signification pour le g6n6rateur 52. Une clause se 
compose d'au moins un mot de s'appliquant a au moins un attribut qui le 
suit. Les clauses illustrees en annexe sont classees en plusieurs types qui ont 
et6 numerates par les lettres A-E en italique et entre parentheses dans le seul 
but de faciliter leur presentation. Cette presentation est faite aussi en 
reference k l'annexe 2 A la pr6sente description et en en faisant partie. 
L'annexe 2 donne simplement une liste explicative des types des clauses 
utilisees, id A-H. 

Dans l'annexe 1A, la dause de type A se compose du mot de 
METHOD JTOJ^TTRIBUTE suivi d*une methode, id getjabel, et d'un 
attribut, id label. Selon l'annexe 2, cette clause indique aux gen6rateurs 52 et 
54 de convertir la methode getjabel en l'attribut label. On notera que le 
convertisseur 52 de services CMIS ne generera aucun service M-ACTION 
mais que les generateur 52 genereront Pattribut specifie. En d'autres termes, 
un clause du type (A) comprend un mot d6 (METHOD JTO_ATTRIBUTE) f 
une premiere caracteristique representative du nom d*une methode et une 
seconde caracteristique representative d'un attribut, le mot de in di quant au 
generateur de convertir ladite methode en ledit attribut 

Dans l'annexe 1A, la dause de type B a le mot de 
MULTTPLE^DECLARE, qui signifie aux genera teurs 52 et 54 qu*ils vont 
trouver une premiere interface induant l'attribut qui le suit, id "hostname" 
et une seconde interface induant aussi cet attribut. II est k noter qu'en 
langage GDMO il est possible d'utiliser la meme definition d'attribut dans des 



classes different d'objets geres (classes MOC). Ainsi, quand les generateurs 
trouvent la premiere interface, ils generent une premiere dasse MOC a partir 
de cette premiere interface et, de meme, quand les generateurs trouvent la 
seconde interface, ils generent une seconde dasse MQC a partir de cette 
seconde interface. lis utilisent done le meme attribut. id "hostname" dans le 
langage GDMO. En bref. dause du second type B comprend un mot de 
(MULTIPLE_DECLARE) et un attribut. le mot de indiquant au generateur 
de generer des dasses d'objets a partir dudit attribut. 

Dans les commentaires de l'annexe 1A, la dause de type C a le 
mot de IGNORE, qui aignifie aux generateur de ne pas traduire le terme IDL 
qui le suit Le terme peut etre notamment un nom dlnterface. un nom 
deception, un nom d'attribut et un nom de methode. Dans l'exemple illustre, 
le terme est un attribut nomme "ActualAttributeValue.t". En d'autres termes, 
les generateurs ne modifient pas le langage IDL pour la conversion. Ce mot 
de offre l'avantage de ne pas generer des choses inutiles dans la description 
GDMO, cela sans toucher au fichier de description IDL. 

La dause de type D a le mot de TYPEDEF. qui indique aux 
generateurs 52 et 54 qull faut remplacer le premier mot qui le suit, 
representadf d'un type du langage GDMO. id 'InterfaceDef, par le second 
mot representatif d'un type du langage IDL. id "Object, normalement defini 
par une partie code dans le fichier de description de l'annexe IB. cette partie 
de code commencant id par un terme nomme "indude" et reference par le 
caractere "T. Cette dause permet de faire des synonymes entre les deux 
langages correspondants. En fait, cette dause est un moyen de definir un 
type de donnees utilise en langage IDL a partir du type de base. Cette 
definition est normalement faite par le verbe "typedef du langage IDL et est 
importee dans le fichier de description a l'aide des termes "indude". Cette 
dause s'explique par Kncapadte des generateurs de l'exemple illustre. pour 
des raisons de limitations imposees par la realisation de ces generateurs de 
chercher les termes "indude" dans le fichier de description IDL. Comme la 
version courante des generateurs utilises dans l'exemple choisi ne gere pas 
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les clauses de precompilation qui commencent par le caractere "#" dans le 
fichier de description IDL de l'annexe IB, il a ete ajoute au fichier de l'annex 
1A du code qui est present avec les termes "include" et necessaire a la 
conversion au debut du fichier de description de l'annexe IB. En outre, dans 

5 le fichier de description de l'annexe IB, il est ajoute une premiere marque 
suivi d'un terme non defini. ici 'Mifdef FOR_GENERATOR_TBfFf et une 
seconde marque "#endif (non Ulustree). Ainsi, le compilateur 55 de la figure 
2 ignore ce qui est entre ces deux marques puisque le terme 
" FOR_GENERATOR_TIME " n'est pas defini. Dans le compilateur, le 

10 preprocesseur (non illustre). qui genere du code C++ a partir du fichier de 
description, ejecte la partie entre les deux marques alors que les deux 
generateurs 54 et 55 vont les prendre en compte. En d'autres termes, on peut 
dire que si les generateurs 52 et 54 ne gerent pas des clauses de- 
precompilation, une clause de troisieme type (D) indut un mot de 

15 CTYPEDEF) et deux mots, le mot de indiquant aux generateurs 52 et 54 quil 
faut remplacer l'un (InterfaceDef) des deux mots, representatif d'un type 
dudit module, par l'autre mot (Object) representatif d'un type du lan gage 
donne IDL normalement defini par une partie de code (sous #indude) dans le 
fichier de description. 

20 Les dauses de type E dans les commentaires de l'annexe 1A sont 

relatives aux liens de nommage, appeles name- binding. Ces dauses sont dues 
au fait quil n'y a pas de liens de nommage entre dasses en lan gage IDL mais 
quil en existe en GDMO. Cette dause permet ainsi d'introduire des liens de 
nommage name-binding dans une definition. Les dauses de type E 

25 comprennent trois mots des SUPER, SUBORD et NAME, suivis 
respectivement de mots (caracteristiques d'objets, attributs, etc.). Le mots des 
SUPER et SUBORD designent respectivement les dasses superieures et 
subordonnees d'objets et le mot de NAME designe I'attribut de nommage de 
la dasse subordonnee. Par exemple, la dause "SUPER orb SUBORD 

30 AgentSystem NAME hostname" indique qu*une instance de la dasse 
"AgentSystem" peut se trouver sous, u etre c ntenue dans, une instance de 
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Ia dasse "orb" et qu'elle est nominee, en tant qu'attribut utilise pour le nom 
RDN, avec I'attribut "hostname" qui appartient a la dasse "AgentSystem". En 
d'autres termes. une dause de quatrieme type (E) comprend trois mots des 
(SUPER, SUBORD, NAME correspondant respectivement a trois 
caracteristiques (orb, AgentSystem, hostname), deux des mots des designant 
par leurs caracteristiques correspondantes deux instances de dasses 
respectivement superieure et inferieure et le troisieme mot de designant par 
la troisieme caracteristique I'attribut de nommage de la dasse subordonnee. 

Les dauses de types F et G de l'annexe 2 sont des dauses 
introductives. Ainsi, la dause de type G sert a nommer le module GDMO 
g6nere par le generateur 54 et la dause de type H sert a nommer le module 
ASNl genere par le generateur 55. 

La dause de type H de l'annexe 2 necessite les observations 
prelimin aires suivantes. Tous les objets semantiques GDMO generes (MOC, 
NameBinding, Package, Attribute) sont identifies par des identifier d'objets 
(Object IDentifiers) tels que definis par la norme ASNl. Ces identifieurs sont 
des suites d'entiers reprenant un meme prefixe. Par exemple, si on alloue la 
suite "1 3 12" comme prefixe, on aUouera automatiquement dans la 
generation automatique les identifieurs "1 3 12 1 1", "1 3 12 1 2", "1 3 
12 1 3", "1 3 12 I 4", ... pour identifier les dasses MOC. puis les 
identifieurs "1 3 12 2 1", "1 3 12 2 2", "1 3 12 2 3". "I 3 12 2 4",... 
pour identifier les liens de nommage name-binding, etc La dause de type J 
permet de demander aux generateurs 54 et 55 de prendre un prefixe different 
de ceux definis precedemraent. Selon notre exemple, la clause "OID.TAG 15" 
demande au generateur de changer le prefixe precedent, id "1 3 12"en"l 3 
15".En fait, Jes identifieurs sont generes 4 l'aide du prefixe, qui est alloue 
dans le systeme d'administration 10 pour le systeme COBA et auquel est 
ajoute un entier supplemental, le nombre 15 dans l'exemple illustre. Cet 
entier supplementaire sert a distinguer des generations en langage IDL entre 
eUes et, done, a distinguer entre eux des modules de base MIB differents. 
Ainsi. s«U existe plusieurs types d'agents implementant des modules 
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differents de base MIB, il est possible de voir tous ces agents dans la base 
NOB du systeme d'administration 10. En d'autres termes, si les objets sont 
identifies par des identifieurs (OID) ayant un meme prefixe, une clause de 
rinquieme type (H) comprend un mot de (OID_TAG) et un entier (15), le mot 
cte indiquant au g6n6rateur de prendre un prefixe different et dSfini par ledit 
entier. 
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ANNEXE 1A 



(zone de commentates) 



II- 



10 



IS 



20 



2S 



30 



35 



//GEN: METHOD_TO_ ATTRIBUTE get_labd labd 

(A) 

It — , 

//GEN: MULTTPLEDECLARE hostname 
//GEN: MULTIPLE DECLARE value 



II- 



//GEN: IGNORE ActualAttriboteValuej 
//GEN: IGNORE AuributeReferencej 



//- 



//GEN: TYPEDEF InterfeceDef Object 
//GEN: TYPEDEF eve* Jype.schemaj string 
//GEN: TYPEDEF AnribnteDef Object 
//GEN: TYPEDEF OpentionDef Object 

// ______ 

//name-bindings : 
(E> 

II 



m 



<Q 



(D) 



SUBORD orb NAMEotbj 
SUBORD Gateway NAME gateway. 



//GEN: SUPER top 
IIGEN: SUPER orb 
// 

//GEN: SUPER orb SUBORD AgentSystem NAME hostname 

//GEN: SUPER OibixServtr SUBORD OrbixOIWroreSegmen, NAME label 

//GEN: SUPER OrbixServer SUBORD OibixBOAScgment NAMEtabd 

//GEN: SUPER OrbixServer SUBORD CORBAAppJ^.K^ObjcaTypeCMO NAME label 



//GEN: SUPER OibixORBCoreSegment SUBORD OrbixConnection 
//GEN: SUPER CORBAApplicationObjectTypeCMO SUBORD 
CORBAApplicalionObjealnstanceCMO NAME label 



NAME label 
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ANNEXE IB 



5 (Ftchier de description IDL) 

findude <ofb.kl> 
findude <HU>fs.idl> 
findude OpcfDf.kO 
10 findude <tnterDf.kfl> 
findude Tirackfl- 
findude "Naming, idl* 
//cssn 

//findude "EvtntManagetnent.kO" 
15 fifdef FOR_GENERAT0R_TIME 

module TimeBase { 

struct uk>ngkmg{ 
20 unsigned long 
unsigned long 

}; 



low; 
high; 



25 
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ANNEXE2 



CLAUSES DE GENERATION 

Usage : gdmo file.idl > fik.gdroo 

//GEN: GDMO_MODULE_N AME jltAdm 
Specif* lenomdu module GDMO generf (par dcfaut 'orbAdm' 
Tones les interfaces iraduites sort declaries enunseul module GDMO. 
Attention : cette clause doit toe placee devant toute instruction IDL. 
(Le generateur ne traduit pas les definitions de module IDL en definitions oonespondantes en GDMO, 
mais cree seulement on module GDMO). 

//GEN: ASN1_M0DULE_NAME Idl2 <°> 
-> nom do module ASN1 fftnttt (par ddfaut : Hdl*) 
Attention : cede clause doit toe placee devant toute instruction IDL. 

//GEN: OTDTAG 15 

-> La valcur pour le composant identifieor (fobfct OID assorie * "corba* 
Pennet <f avoir dilRrentes generations poor utiliser dilKrents identifieurs OlDs ... 

//GEN: METHOD JTO_ATTRIBUTE getjabel label (A) 
-> La mdhode "getJabeT est traduite en rattribut label 9 
La syntaxe retournec par la rndthode est utilisde comme type (fattnbut. 
Aucune m-action est gencrce pour la mAhode, seulement rattribut speriM. 

//GEN: MULTIPLE_DECLARE hostname W 
> Quand un metne nom d'attribut est utilise dans difKrcntes interfaces IDL, oca avertit le generate!* de 
produire seulement une definition d'attribut GDMO. 



(H) 



//GEN: IGNORE EvertSchemaMetaDef <0 
-> Specific que Hnterfoce donnee n'a pas * etre traduile en GDMO. 

//GEN: TYPEDEF InterfeceDef Object @) 
-> Ptrmet de definir un type qui est normalement defini avec le terme "include*. 
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//GEN: SUPER root SUBORB AgenlSystem Nam hostname (E) 
-> lien de nocnmage name-binding i gftitar 

Sptofie : classes <fobjets suptaeurcs cl subordonn&s (ou noms <f interface qui son! i traduirc en ooms 

MOQl 

"root" petit etre sptofte pour la classe MOC sous la racine de la MIB. 
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R vendications 

1. Precede de generation automatique d'un module (19) d'une 
base d'informations d'administration (MTB) d'une ressource informatique (11) 
5 representee par objets et incluant une architecture d'objets distribues 
(CORBA) selon un langage donne (IDL), consistant a faire un fichier 
(annexe IB) de description d'interface dans le langage donne et a appliquer 
ledit fichier a des moyens de generation automatique (52) pour obtenir une 
partie dudit module, caracterise en ce qu'il consiste a ajouter audit fichier de 
10 description un fichier (annexe 1A) de clauses de generation automatique, une 
clause comprenant au moins un mot cle determinant un mode de generation 
et au moins une caracteristique sur laquelle porte un mot cle, et a appliquer 
le fichier de clauses auxdits moyens de generation pour completer ledit 
module. 

15 2. Precede selon la revendication 1, caracterise en ce que le 

fichier de clauses et le fichier de description ne foment qu'un seul fichier 
(100), Tun (annexe 1A) des deux fichiers etant distingue de l'autre par une 
marque (GEN). 

3. Precede selon la revendication 1 ou 2, caracterise en ce qu'une 
o clause d'un premier type (A) comprend un mot cle 
(METHOD_TO_ATTRIBUTE), une premiere caracteristique representative 
du nom d'une methode et une seconde caracteristique representative d'un 
attribut, le mot de indiquant aux moyens de generation de convertir ladite 
methode en ledit attribut. 

5 4. Precede selon l'une des revendicationa 1 a 3, caracterise en ce 

qu'une clause d'un second type (B) comprend un mot cle 
(MULTIPLE.DECLARE) et un attribut, le mot cle indiquant au generateur 
de generer des classes d'objets a partir dudit attribut. 

5. Precede selon l'une des revendications 1 a 4, caracterise en ce 

• qu'une clause de troisieme type (Q comprend un mot cle (IGNORE) et une 
caracteristiqu , 1 mot cl* indiquant aux moyens de generation d'ignorer 
ladite caracteristique. 
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6. Precede selon Tune des revendications 1 a 5, caracterise en ce 
les moyens de generation ne gerant pas des clauses de precompilation, une 
clause de troisieme type (D) inclut un mot cle (TYPEDEF) et deux mots, le 
mot cle indiquant aux moyens de generation qu'il faut remplacer Tun des 

5 mots (InterfaceDef) par l'autre mot (Object) representatif d'un type du langage 
donne normalement defini par une partie de code (sous #include) dans le 

fichier de description. 

7. Proced6 selon Tune des revendications 1 a 6, caracterise en ce 
qu'une clause de quatridme type (E) comprend trois mots cles (SUPER, 

10 SUBORD, NAME correspondant respectivement a trois caracteristiques (orb, 
AgentSystem, hostname), deux des mots cles designant par leurs 
caracteristiques correspondantes deux instances de classes respectivement 
superieure et inferieure et le troisieme mot cle designant par la troisieme 
caracteristique l'attribut de nommage de la classe subordonnee. 

15 8. Precede selon Tune des revendications 1 a 7, caracterise en ce 

que les objets etant identifies par des identifieurs (OID) ayant un meme 
pre fixe, une clause de cinquieme type (H) comprend un mot cle (OIDJTAG) et 
un entier (15), le mot cle indiquant au generateur de prendre un prefixe 
different et defini par ledit entier. 

20 9. Precede selon Tune des revendications 1 a 8, caracteris6 en ce 

que les moyens de generation comprennent en outre un generateur (54) pour 
la generation automatique d f une partie (51c) d'un integrateur d'agents 
d'administration (51). 

10. Systdme d'administration (10) d'une ressource informatique 

25 (11) representee par objets definis dans une base deformations 
d'administration (MIB) incluant un module, le systeme d'administration 
incluant au moins un processeur (14) et des moyens de memoire (15) et la 
ressource informatique incluant une architecture d'objets distribues (CORBA) 
selon un langage donne (IDL), caracterise en ce qu'il met en oeuvre au moyen 

30 d'au moins ledit processeur (14) le proced' defini par l'une des revendications 
precedentes. 
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